Перейти к основному содержимому

Задание 4: MVP

🚀 Четвертая контрольная точка проекта - Демонстрация Minimum Viable Product

📋 Формат и требования​

  • Формат: Очная защита с презентацией (5 минут + 5 минут вопросы)
  • Дедлайн: 14 февраля 11:00 (загрузка), 13:00 (защита)
  • Материалы для загрузки:
    • Презентация (PDF): цели, User Story Map, сценарии, демонстрация MVP, архитектура (C4 L1–L2, развёртывание).
    • Ссылка на репозиторий (GitHub или GitLab): исходный код, README со структурой репозитория и инструкцией по запуску, настроенный CI (линтеры).
  • Пересдача: Коэффициент 0.6 (21 февраля), 0.4 (28 февраля)

📝 Описание​

Четвертая контрольная точка проекта, на которой команда должна продемонстрировать MVP.

До защиты допускаются команды, которые загрузили артефакты до дедлайна включительно. Команды, которые не загрузили артефакты до дедлайна должны загрузить ее для защиты с понижающим коэффициентом и защитить на следующей защите.

На презентации выступает вся команда. Отсутствующие получают оценку "0", отсутствующие могут защитить презентацию на следующей защите с понижающим коэффициентом.

У студентов есть только 2 недели для досдачи, пересдать позже нельзя.

⏰ Сдача после дедлайна​

  • Коэффициент 0.6: Загрузка до 21 февраля 11:00, защита 21 февраля с 13:00
  • Коэффициент 0.4: Загрузка до 28 февраля 11:00, защита 28 февраля с 13:00

📊 Критерии оценивания​

Итоговая оценка выставляется по шкале от 0 до 10 по уровню реализации MVP. Учитываются: презентация продукта, архитектура приложения (нотация C4), репозиторий и код, возможность запуска без разработчика. Сбор и использование обратной связи от пользователей обязательны только для оценок 9–10.

Обязательные требования к артефактам​

Формат сдачи должен соответствовать следующим требованиям:

Репозиторий и код

  • Исходный код размещён в открытом репозитории на GitHub или GitLab.
  • Структура проекта продумана: разделение на модули/пакеты, понятная навигация по коду.
  • Код проходит линтеры (ESLint, Pylint, Black, Ruff и т.п. — в зависимости от стека); конфигурация линтеров в репозитории.
  • Линтеры запускаются автоматически в CI (GitHub Actions, GitLab CI или аналог); в репозитории есть рабочий pipeline/ workflow.

README

  • Описание проекта и его целей.
  • Описание структуры репозитория (назначение основных папок/модулей).
  • Инструкция по запуску: зависимости, установка, команды для запуска приложения и (при необходимости) тестов.
  • Требования к окружению (версии языка, СУБД и т.д.) — при необходимости.

Архитектура (в презентации или в репозитории)

  • Диаграмма C4, уровень 1 (Context): система в контексте пользователей и внешних систем.
  • Диаграмма C4, уровень 2 (Container): основные контейнеры приложения (фронтенд, бэкенд, БД и т.д.) и связи между ними.
  • Диаграмма развёртывания (Deployment): где и как разворачиваются компоненты (серверы, контейнеры, облако).

Презентация (PDF)

  • Цели проекта и заявленная проблема.
  • User Story Map и ключевые сценарии MVP (приоритизация MoSCoW — при необходимости).
  • Как продукт решает заявленную проблему.
  • Демонстрация работы MVP (скриншоты или сценарий использования).
  • Итоговая архитектура (C4 L1–L2, развёртывание).

Реализованный функционал

  • Планы на MVP берутся из последних актуальных планов с задания Прототип (Задание 3): User Story Map, сценарии и приоритизация, зафиксированные на защите прототипа или в обновлённых артефактах к моменту защиты MVP.
  • Оценки 6–8: реализованный функционал должен соответствовать планам на MVP (из задания Прототип). Достаточно полного выполнения запланированного на этап MVP.
  • Оценки 9–10: реализованный функционал должен быть больше, чем планы на MVP: включены элементы следующего этапа — MUP. То есть реализовано не только всё запланированное на MVP, но и часть функционала, запланированного на MUP (расширенная пригодность к использованию, доработки по обратной связи, дополнительные сценарии и т.п.).
  • Планы на MVP и MUP обязательно приводятся в артефактах (в презентации и/или в репозитории): в User Story Map или в отдельном разделе презентации должны быть явно отмечены сценарии и функции, относящиеся к этапу MVP и к этапу MUP, чтобы проверяющий мог сопоставить реализованный функционал с планами.

Опросы и обратная связь пользователей (обязательно для оценок 9–10)

  • Проведены опросы или сбор обратной связи от пользователей (анкеты, Google Forms, Typeform, NPS, интервью и т.п.).
  • Результаты представлены в структурированном виде (таблицы, графики, диаграммы).
  • Проведён анализ: выделены основные проблемы, запросы и предложения пользователей.
  • В презентации или в репозитории описаны конкретные изменения в продукте, сделанные по результатам обратной связи.
  • Для оценки 10: обратная связь от широкой аудитории, включая целевую; глубокий анализ с визуализацией; структурированные методы сбора (рейтинги, NPS, интервью).

Шкала оценок 0–10​

Оценка выставляется по совокупности выполнения требований. Ниже для каждой оценки перечислены ожидаемые уровни по пунктам.

0 — Дееспособный результат отсутствует.

  • Нет рабочего продукта или презентация не отражает MVP.
  • Архитектура не представлена или не соответствует задаче.
  • Запуск без разработчика невозможен; исходный код недоступен или непригоден (например, критические ошибки, отсутствие репозитория).

1 — Продукт в зачаточном состоянии.

  • Есть код или макеты, но решение не достигает уровня MVP (нет отчуждаемости или не выполняются базовые функции).
  • Презентация не раскрывает цели и сценарии MVP.
  • Архитектура с серьёзными пробелами или не соответствует проекту.
  • Запуск требует участия разработчика или действий, несвойственных пользователю (например, правка кода, сложная ручная настройка).
  • Репозиторий может отсутствовать или не соответствовать требованиям (структура, README, CI).

2 — Частичная реализация MVP.

  • Продукт частично работает, но с критическими ограничениями (например, только для одного пользователя, без инструкций по запуску).
  • Презентация описывает продукт поверхностно, без чёткой связи с целями и User Story Map.
  • Архитектура указана частично, с существенными недочётами (нет C4 L1/L2 или развёртывания).
  • Репозиторий на GitHub/GitLab есть, но README неполный, структура не описана, CI/линтеры отсутствуют или не настроены.

3 — Минимальный уровень MVP.

  • Продукт в целом выполняет заявленные функции, но с заметными недостатками.
  • Презентация содержит описание и цели, но без полноценной демонстрации сценариев и связи с архитектурой.
  • Архитектура отражена в диаграммах (C4 или аналог), но с недочётами (неполнота, ошибки нотации).
  • Запуск возможен без разработчика, но инструкции в README неполные; структура репозитория не описана или не продумана.
  • Линтеры и CI отсутствуют или не проходят стабильно.

4 — MVP на границе удовлетворительного.

  • Презентация, архитектура и запуск присутствуют, но каждый аспект с ограничениями.
  • Презентация показывает продукт и сценарии, но без чёткого обоснования «как решает проблему».
  • Представлены C4 уровень 1 и уровень 2 (или эквивалент), возможны несущественные ошибки; диаграмма развёртывания может быть упрощённой.
  • Репозиторий на GitHub/GitLab, README есть и позволяет воспроизвести запуск, но описание структуры репозитория отсутствует или краткое.
  • Код структурирован частично; линтеры могут быть настроены, но не в CI, или CI не стабилен.

5 — Удовлетворительный MVP.

  • Продукт выполняет базовые задачи; презентация отражает цели, сценарии и демонстрацию работы.
  • В презентации или в репозитории: диаграммы C4 уровень 1, уровень 2 и диаграмма развёртывания, решающие ключевые задачи проекта.
  • Репозиторий на GitHub или GitLab: исходный код доступен, README с инструкцией по запуску и описанием структуры репозитория.
  • Запуск без разработчика по README возможен; код в целом структурирован.
  • Линтеры настроены и проходят; CI (GitHub Actions / GitLab CI) настроен и автоматически запускает проверки (например, линтеры).

6 — Хороший MVP.

  • Реализованный функционал соответствует планам на MVP из задания Прототип (User Story Map, сценарии, приоритизация).
  • Презентация связно показывает цели, User Story Map, сценарии и скриншоты работы; видно, как продукт решает заявленную проблему.
  • Архитектура представлена чётко: C4 L1, C4 L2, развёртывание; компоненты и взаимодействия соответствуют проекту.
  • Репозиторий: продуманная структура проекта, README с описанием репозитория, структуры и инструкцией по запуску; код структурирован, линтеры проходят, CI запускает линтеры автоматически.
  • Продукт стабильно работает по документации; пользователь не выполняет действий, несвойственных его роли.

7 — Выше хорошего.

  • Всё на уровне 6, плюс:
  • Реализованный функционал полностью соответствует планам на MVP из задания Прототип (все запланированные сценарии и функции реализованы).
  • Презентация включает шаги от прототипа к MVP и обоснование архитектурных и технических решений.
  • Диаграммы C4 и развёртывания полные, с акцентом на ключевые задачи; нотация соблюдена.
  • Код соответствует принятым стандартам (стиль, именование); технический долг минимален; CI стабильно зелёный.

8 — Сильный MVP.

  • Реализованный функционал полностью соответствует планам на MVP из задания Прототип; продукт готов к использованию в рамках заявленного MVP.
  • Презентация и демонстрация на высоком уровне; продукт показан как готовый к использованию.
  • Архитектура полная: C4 L1, C4 L2, развёртывание; диаграммы готовы к использованию в разработке и развитии.
  • Репозиторий: структура продумана и описана в README; README содержит инструкции по запуску, настройке окружения и типовым сценариям использования.
  • Код структурирован, линтеры проходят, CI автоматически запускает проверки; запуск и использование не требуют разработчика.

9 — Очень сильный MVP (обязательны: функционал сверх MVP → MUP, сбор обратной связи).

  • Реализованный функционал выходит за рамки планов на MVP: включены элементы следующего этапа — MUP (дополнительные сценарии, доработки по обратной связи, расширенная пригодность к использованию).
  • Всё на уровне 8, плюс:
  • Продукт развёрнут или готов к развёртыванию в целевом окружении.
  • Презентация отражает полный путь к MVP и расширенный функционал (в т.ч. элементы MUP); архитектура детализирована и обоснована.
  • Код без явного технического долга; возможны базовые тесты; документация позволяет быстро запустить и настроить продукт.
  • Обязательно: собрана обратная связь от пользователей, проведён её анализ, в продукте сделаны конкретные изменения по результатам отзывов (отражено в презентации или в репозитории).

10 — Отличный MVP (обязательны: функционал сверх MVP → MUP, сбор обратной связи).

  • Реализованный функционал существенно выходит за рамки планов на MVP: реализована значимая часть следующего этапа — MUP (расширенная пригодность к использованию, дополнительные сценарии, доработки по обратной связи, улучшенный UX и т.п.).
  • Продукт внедрён на месте применения и используется с расширенным функционалом (в т.ч. элементами MUP).
  • Презентация и защита демонстрируют полное понимание продукта, целей и сценариев; архитектура (C4 L1–L2, развёртывание) представлена полностью и готова к реализации и развитию.
  • Репозиторий: структура продумана и описана; README с инструкциями по запуску, структуре и сценариям; код структурирован, линтеры в CI проходят; есть тесты; документация качественная.
  • Продукт запускается без разработчика; пользователь не выполняет действий, несвойственных его роли.
  • Обязательно: обратная связь от широкой аудитории; структурированные методы сбора (анкеты с рейтингами, NPS, интервью и т.п.); глубокий анализ с визуализацией; конкретные улучшения продукта на основе отзывов (описаны в презентации или в репозитории).

🔗 Связанные документы​

  • Задание Прототип (источник планов на MVP): Этап 3 — Прототип
  • Критерии оценивания: см. раздел выше
  • О курсе и расписание: О курсе
  • FAQ: FAQ